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flowing down tho field line maaked by the dashed horizontal 
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Figure 1 is eoineidont with this RIMS pass. ,t0 

The low-energy H >• plasma data from tho RIMS oxperiaient is 
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difference in tho angular distribution of those two ions when 

compaidng the bottom two panels of this and the previous figures , , . XI 
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Tho F region trough at invariant latitudes near 70 degrees maps along 
magneiic field lines to DR l altitudes at 12,500 km whore the lUMS 
doteetor measures IM ions that have a conical pitch angle distribution. 13 

The corresponding RIMS DR»I spectrogram for the Chatanika 

data shown in Figure i. The data is plotted such tluvt the 

invariant latitude of the DE-1 spaeeeraft matches that 

measured by the Chatanika rudar in the pnn'ious figure. For 

uox'roiatlvo purposes these llgures (4 and 5) can be placed over 

one another, Note that tho field-aligned flows measured by RIMS 

map to regions of relatively Ivigh donsitios in tho X*' (350 km 

altitude) layer of the ionosphere (300 to 1200 km north) 14 

Another RIMS spectrogram but tbr low-energy On'' ions. Note 

the up going 0 t» ions (along the solid horizontal lino in the 

bottom panel), These flows aro seen only during time when 

no II I and He+ flows are measured. 16 
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TECHNICAL MEMORANDIUM 
MSFC SCAN STAGE 1 WORKSHOP 
I. INTRODUCTION 


The NASA Data System Technology Program (DSTP, formerly called the NASA’s 
End“tO“End Data System or NEEDS) is developing concepts and demonstrating 
technology that will significantly reduce the time required for acquired spacecraft 
data to reach the experimenter [1], At Marshall Space Flight Center (MSFC), the 
DSTP consists of two systems: a Data Base Management System (DBMS) and a Mass 
Memory Asseaibly (MMA) . The DBMS will eventually consist of several large mini- 
computers linked together by a high-speed, fiber optics bus with powerful data 
base management software to handle large quantities of data [2]. Presently, the 
DBMS computer system is comprised of one Digital Equipment Corporation VAX 
using the VMS standard operating system. Two other VAX computers and the fiber 
optics link between them will be installed at MSFC in May 1983. The part that the 
MMA plays is to stox’e large multiple data buses at the central DBMS site in a large 
permanent archive [ 3] . The MMA is currently planned to be integrated into the 
DBMS computers in about May 1984. 

The MSFC SCAN (Space plasma Computer Analysis Network) system is being 
designed around the construction of the DSTP here at MSFC. The SCAN network 
links several remote users to the DBMS computers. At this time, the network is 
configured so that there are seven "remote" (not at the central site) nodes in the 
network: the Univex’sity of Texas at Dallas (UTD) , Utah State University, Stanfox’d 
University, the University of Iowa, Los Alamos National Labox*atory, Ooddax’d Space 
Flight Center, and the Space Science Labox’atoxy (SSL) at MSFC. Each of the 
remote nodes has a direct line into the DSTP system. 

There are sevex’al capabilities and features that the SCAN netwox’k is 
developing, making it unique within the space science community. The SCAN 
network provides I’emote nodes with access to growing space science data bases 
and bi’ings scientists throughout the countxy together in a common wox’king 
environment. Unlike all past space science netwox’ks, where the remote sites have 
only remote terminals (supporting one person at the remote site at a time), the 
SCAN notwoi’k supports many users simultaneously at each remote node through 
computer to remote computer communication software. Users at their institutions can 
participate in a number of network functions involving the central DSTP computer 
facilities and other remote computer facilities. Data files and gxmphics files can be 
transfex’X’ed to and fx’om the DSTP DBMS and other remote facilities, Px’ogram 
execution can be initiated from any of the netwox’k nodes (disti’ibutive pi’ocessing) . 
The DBMS facility has a gx’owing library of analysis softwax'e that can be trans- 
fex’red to x’emote nodes or executed at the centx’al site. For example, the user at 
a remote site can initiate a library program at the central site which reads and 
analyzes data out of the mass memoi’y assembly and then have the I’esults tx’ans- 
ferx’ed to his node. The MMA used dux'ing interim development (until May 1984) 
is simple disk stox’age. All of the nodes have the capability for message x’outing, 
enabling the remote nodes to communicate to each other as if a dix’ect phone line 
existed between them, even though they may not be "adjacent" nodes. 


The most important feature of this network is that remote users have easy and 
immediate access to geophysical measurements; this has been clearly demonstrated 
during workshop periods. A workshop period enables physicists to attack a science 
problem by interactive analysis, utilizing all available computing facilities resident at 
the scientist’s institution as well as at the central DBMS node (also called the NEEDS 
node in this report). All users have access to the entire data set before, during, 
and after the workshops. This enables everyone to become familiar with the data and 
how to use the network before the workshop. The workshop activities continue long 
after the initial meeting, thus allowing for maturing of scientific ideas. For every 
workshop each participating network node is responsible for furnishing data analysis/ 
display programs that analyze their data set and that can run on any of the 
computers in the network. Different data bases reside at the various network nodes 
and at the central site, thus utilizing both central and distributive computer pro- 
cessing. It is essential to realize that much activity takes place over the network 
during non-workshop periods since the network is available to everyone 24 hr a 
day, every day. A workshop should be considered only, the peak of an ongoing 
analysis scenario over an extended period. The first SCAN Network Workshop was 
held at MSFC on August 19-20, 1982, with others being planned around the further 
enhancement of the DBMS central facility for 1983. The network configuration used 
during the first workshop is shown below. 


NEEDS 

-VAX- 11/ 7 80- , 

DECnet-VAX 

1 I 

UTAH 

I PDP-11/70 

UTD DECnet-IAS 

PDP-11/23 
RSX DECnet 


The NEEDS (the central DBMS computer that all remote nodes are connected to) 
and SSL nodes are located at MSFC in different buildings while UTD and UTAH are 
very distant nodes in Texas and Utah, respectively. Note that not all nodes that 
were currently on the network (i.e., Iowa, Stanford, Los Alamos, and GSFC) were 
involved in the workshop. Preparation for the workshop began nearly 6 months 
earlier when these nodes were not on the network. 

The purpose of this report is not only to document the first in a series of 
science workshops using the SCAN network but to serve as a guide to other nodes 
who are planning to hold workshops of their own. The workshop procedure, as 
discussed in this report, clearly indicates that the network can support simultaneous 
wox’kshops if sufficient planning is made. 
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SSL 

PDP-11/34 
RSX DECnet 
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II. WORKSHOP PHILOSOPHY 


The (icvolopmont ol' a cohorGiit and offcctivo SCAN network philosophy is 
necessary for network scientists to he able to utilize the network as a scientifie 
analysis tool. In March 1982, a series of tolecons were held wiiero voice communi- 
cation was established between SSL, UTD, and UTAH nodes. The telecons wore 
necessary first to identify the workshop objectives and second to determine how to 
carry out those objectives. These early telecons wore veiwed as practice workshops 
"runs," since they enabled the scientists to detoi’mine what software was needed to 
accomplish set g'oals. 

The objectives of the network were generally agreed to be: (1) the development 
of the SCAN network as an effective tool for coordinated scientific data analysis of 
multifarious data bases, and (2) use of the coordinated data bases to conduct 
scientific analysis. A better understanding of "lonosplieric transport into the 
Magnetosphere" was chosen as the overall science goal. The question of how to 
utilize the network to accomplish the above goals will always be dependent on the 
available hardware/software, processing power, and the number of participants. The 
discussions in the telecons concerning the oest use of the network during the first 
workshop centered around two major topics; The I’ole of the "remote" versus "in 
person" workshop envix’onment (discussed extensively in a latter section), and the 
use of remote site versus a centimlized data base system. 

Witli regard to the workshop environment, it was decided that both "remote" 
and "in person" workshops should play a role in an ongoing analysis px'ogram. 

During the telecon discussions, it was agreed that an "in person" workshop was 
important to expedite the process of familiarization of the group with the various 
data sets and to renew excitement about specific analysis topics, Continued remote 
workshops held after the formal "in person" workshop would lend themselves well 
to continued detailed scientific analysis of the data sets, since detailed analysis 
requires both careful study and extended preparation periods. It vvas believed 
important that the first workshop should be conducted from a single location. In 
addition to maximizing the interaction between different scientists, this would also 
allow the workshop activity and progress to be easily monitored. The Data Analysis 
Laboratory (DAL) at SSL was chosen as the sight of the first workshop, since it is 
a room sufficiently spacious to accommodate up to a dozen people working on data 
analysis. The DAL is equipped with microfiche readers, slide and overhead pro- 
jectors, three alphanumeric terminals, three monochrome terminals (4014 type), and 
one color (4027) terminal. Two of the 4014-type and the 4027 terminal have hardcopy 
facilities. Chalk boards, paper, and other miscellaneous materials were also pi’ovided. 

Ill terms of the location of the data, it was decided to try a combination of 
centi’al and remote data bases. The btSL node chose a centralized data base approach. 
In this approach, both data and analysis software are resident on the central NEEDS 
node. To generate the required analysis output, one simply signs on to the NEEDS 
computer, runs the appropriate program, accesses packetized data out of the 
archive, and directs the appx'opriate output to the desired x’emote node (more 
complete discussion of this procGedux'*G is in Section 5, 6, and 7 of the Appendix.) 
The UTD approach has been to maintain a remote data and software base. The UTD 
processing computer (a PDP 11/45), however, is not connected directly to the 
netwoi’k. Data analysis plot files are generated on the 11/45 and transfex’red bj'- 
floppy disc or by dix’ect link using a local data transfer px'ogram to the 11/23 
(which is connected to the centx’al NEEDS node by phone line). This X'esults in the 
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inability to oai'i*y on intoractivo analysis of tho UTD data from other remote nodes 
without some local UTD support and preparation. UTD recognizes this as a restric- 
tion; thus, a more convenient method of file transfer between their computers is 
currently being developed. The UTAH node used a combination of the two data base 
appi’oaches. Some of their data was resident in data files on tho DBMS computer (not 
packotized, however) and some on the UTAH PDF 11/70. Limited data analysis 
software was developed at the NEEDS node to cope with tlvo UTAH data interactively. 
Contributions to this software were accomplished by both SSL and UTAH personnel. 

Another major goal was to develop the ability to have graphic displays of data 
from any node to be displayed by any other node (see Section VIII for a more ex- 
tensive discussion) ♦ The easiest way to accomplish this was to generate a graphics 
file and U’ansfor a copy of it to a remote node. Then, at the remote node, the file 
is sent to the device as if it was a text file. In doing this, a number of problems 
were immediately found; 

1) The Tektronix 4027 plot files generated ot UTD (with tho IGL plotting 
package) were not displayed appropriately on the SSL 4027. However, the 
4027 plot files generated at SSL (with the MSSL plotting package) were 
displayed correctly by UTD. This problem was tracked down to the way IGL 
generates its graphics files and tho IISX-IIM file transfer program. This 
was corrected when UTD wrote a piNigram wldch corrected the graphics 

file typo when the file was transferred over tho network. 

2) UTAH did not have any device compatible with tho Tektronix 4027. A 
program was written by UTAH to convert both 4027 and 4Q1Q device 
commands into commands understandable to their Versatec printer-plotter, 

It is tdso desirable to have the ability to plot a graphics file without copying it 
to a remote node first. This would eliminate the waste of disk space by duplicate 
copies of files that exist elsewhere on the network. To h{\ndlo this situation, UTD 
wrote the first version of a program which opens up the network and reads a 
"remote" file. SSL has added other capabilities (see Section 9 of the Appendix) to 
that software to allow for automatic hardcopy capability, Utah's Versatec program 
does the same, reading records as needed from anywhere on the network without 
copying whole files. 


The inability of all the nodes to examine the same plots on different devices 
was immediotely recognized. The above approach to solve this problem was im- 
plemented within a few weeks periods but only ns temporary solution. A final 
solution appears to be the full development of a network standard for the form of 
device-indepondont plot files. Currently being studied through the network is the 
implementation of either the IEEE device-indopendent format standard or a similar 
one used at Los Alamos National Laboratory, 


III. DATA BASES AVAILABLE 


There were three data bases that were used in this workshop: the SSL RIMS 
data from DE-1 (residing in the interim DBMS archive in packetized form at the 
NEEDS node) , IDM and RPA data (residing in file form in the NEEDS computer and 
at UTD) , and the UTAH Chntanika data (also residing in data files in the NEEDS 
computer). Each of these data bases has their own analysis software (discussed in 
the See tion IV and the Appendix). 
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TliG SSL data wore obtained by the DE/RIMS instrument aboa?’d the DE~1 space- 
eraft which hos a highly elliptical precessing polar orbit which cot n*s the altitude 
range 600 to 21,600 km. The RIMS instrument uses a combination of retarding 
potential analysis and magnetic ion mass spectrometry techniques to measure the bulk 

-l 6 3 

plasma parametox's of ion density (10 to 10 particles /cm ), temperatux’e 
(0 to 45 eV), and bulk flow (>0.5) km/sec) in the inner plasmasphere and ionosphere 
and the specific ion pitch angle and energy spectral characteristics in the outer 
plasmasphere and plasma trough for selected mass species in a mass range of 1 to 32 
amu [4]. Three identical perpendicularly-oriented heads provide tlu’ce-dimensional 
coverage of the basic thermal plasma parametex^s. 

The UTAH data contains thermal ion density and flow measurements obtained 
with the Chatanika incoherent radar facility [5]. The measux’ements extend from 0 to 
750 km in altitude and 2400 km in the north-south dix’ection. These measux’ements 
ax’e centered at 65 deg invariant latitude (IL) and extend fx’om 55 to 76 dog IL. The 

3 6 3 

incoherent radtxr can measux*e ion densities from 10 to 2 x 10 particles /cm and the 
line of sight component of the ion flow velocity of up to 4 km /sec with an uncertainty 
of about 100 m/soG. 

The UTD data is composed of ion density, tempex’ature , and flow measurements 
obtained from the Retarding Potential Analyzer and Ion Dx’ift Meter (RPA/IDM) 
aboard the DE-2 spacecraft [6,7]. The DE-2 spacecraft has a near circular orbit 
which is cQ-planar with the DE-1 spacecraft. The xmnge of altitude covex’age is fx'om 

300 to 950 km. The RPA/IDM measux’es ion densities fx’om 10^ to 10^ 
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particles /cm , ion tempex’atux’es fx’om about 300 to 5000 K, and three-dimensional ion 
flow velocities from 0 to about 4 km /sec. 

Dux’ing the eax’ly telecons, four days of magnetosphex’ic and ionospheric data 
fx’om the data sets described in the above were chosen to be studied dux’ing the 
wox’kshop pexnod. These days wex’e October 24, 25, 26, and 29, 1981. The main 
ci’itexuon for selection was the large aaiount of ovex'lapping data that already existed 
fx’om these expex’inients during those times. 


IV. WORKSHOP PREPARATION 


This section will discuss the px'oblems encountered with adapting, identifying, 
and wx’iting utilities to accommodate data analysis for all the nodes on the system. 

The big advantage of using a networking system like SCAN is that wx'itten netwox’k 
utility pi'ogx’ams are x'eadily available and can be used by all the nodes, therefore 
eliminating duplication of px'ogx’amming effox't. Unfortunately, in order to x'ealistically 
assess what and how much science can be done, duxing a workshop, a somewhat 
detailed knowledge of each computer system is needed. 

Since the SSL node was used during the formal wox’kshop as the command node, 
netwoi’k px’ovisions (px’ogx'ams) had to be created that would allow for both submission 
of progx’ams from SSL to I’un on tlxe NEEDS computer and a plot replay capability 
(back to the ox'iginator node) for examining the x’esults. It is important to note that 
the SSL node has only a PDP 11/34 (a mini-computer) for processing and connection 
to the n^twoi’k. The biggest constx’aint imposed by the SSL 11/34 on wox’kshop and 
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network activities is its limited memory size (256k bytes). Almost half of this is 
taken up with the RSX-*11IVI operating’ system and resident network tasks, leaving 
approximately 128k bytes for user (workshop) tasks, It was obvious that local pro- 
cessing (apart from the file replays) could not be allowed during the workshop, so 
remote computers were used for running analysis programs. For network file trans- 
fers into or out of the SSL 11/34, the Network File Transfer (NFT) program supplied 
by Digital Equipment Corporation (DEC) as part of their DECNET software worked 
extremely well, However, for logging onto remote computers DEC has only the un- 
supported RVT (Remote Virtual Terminal) uode. One of us (Joe Doupnik) rewrote 
and expanded RVT to support the needed remote log on capability before the work- 
shop. A ’'bug'* in the RSX-llM operating system would not allow the RVT program 
to be properly checkpointed (roll-out to disk) , meaning that RVT had to be run 
with the checkpointing inhibited (stay-in memory) , further reducing the available 
memory (about 12k bytes/copy). Since RVT, NFT, and the plot replay programs are 
all less than approximately 20k bytes, three copies of RVT and two copies of the 
plot replay programs could be executed simultaneously. But even with memory and 
running task limitations, the SSL node was able to handle all the desires of the 
workshop participants. In the 2-day period of the workshop, there were nearly 85 
spectrogram plots generated and more than a dozen line plots. Vendor assistance in 
the area of network software has been, and still remains, extremely difficult to 
obtain. The rewritten RVT program is being used continuously by all the PDF nodes 
on the network since the workshop and has provided an excellent method for logging 
onto remote nodes. In addition, the checkpoint problem has also been solved in the 
post-workshop analysis phase. 

Before the workshop period, a good deal of data analysis software was also 
developed between the nodes. An especially good example of the cooperative software 
development was the Chatanika mexddian scan program. In early April (1982), Utah 
personnel (Joe Doupnik and John Foster) placed into the central NEEDS node much 
of the workshop Chatanika data for use by anyone on the network. Several people 
from SSL (Julian Johnson and James Green) wrote a color-coded plot program for 
this data. Guidance from Joe on this programming task was obtained during this time 
by use of the VMS network mail system. Before the workshop, Joe also spent an 
afternoon on additional coding changes which enabled interactive changes in the 
color /density correspondence within the program. During the workshop much use of 
this program was made to examine details of the ionospheric density gradients which 
enabled the scientists to get a better understanding of the variability of ionospheric 
density profiles. Since the workshop, increased interest in the Chatanika radar 
measurements is evident in the three additional analysis programs developed so far. 
The coordinated effort in the displaying and analyzing of the Chatanika data has 
proven to be extremely beneficial, since the new display) techniques (originally 
developed by SSL personnel for the RIMS data and applied to the radar data) have 
shown additional details in the Chatanika data not previously recognized by the 
scientists at UTAH. 

Once the networking and analysis software was in place, data overviews for all 
three data sets (RIMS, Chatanika and RPA/IDM) were generated in plot file (and 
hardcopy) form prior to the workshop for everyone to examine (plot files were left 
on the network). For example, the RIMS summaries consisted of sixteen, 6-hr color 
spectrograms. The Chatanika data set consisted of meridian scans representing 
ionospheric plasma densities in the topside ionosphere (program discussed earlier) 
as a function of altitude and north-south distance from the radar site (not all 
available plots used were generated prior to the workshop). The intention in the 
workshop was to run a battery of data analysis programs interactively to "home in" 
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on whatever data intervals and plot formats were required to satisfy the scientific 
goals of the workshop. 


V. OPERATION OF THE WORKSHOP 


The workshop control center was at the Magnetospheric Physics Branch, Space 
Science Laboratory (the SSL node) which is a x’emote node. Rod Heelis (University of 
Texas at Dallas) and Joe Doupnik (Utah University) were present to represent their 
respective remote network nodes. The Magnetospheric Physics Branch remote node 
was represented by Jim Green, Hunter Waite, Julian Johnson, Tsugunobu Nagai, and 
Rick Chappell. From the SSL node, a phase of concentrated scientific study on the 
collective Dynamics Explorer (DE) and Chatanika incoherent radar data bases was 
initiated. 

The first morning of the workshop was used to clarify the general philosophy of 
the data network as a scientific tool and to familiax’ize the participants with the 
different aspects of the data bases. This was accomplished by distributing copies of 
the workshop guidelines (the Appendix) and discussing the details of that document 
with everyone. In addition, copies of the Appendix were put in the NET /NET account 
on the NEEDS central node so that remote participants would have easy access to the 
workshop guidelines. Next, Rod Hcnlis, Joe Doupnik, and Hunter Waite briefly went 
over the overview plots of each of »he data sets. 

As mentioned earlier, four days of overlapping data acquisition had been chosen 
several months prior to. the workshop. This enabled the completion of preliminary 
data processing and examination before the workshop began. In the process of 
familiarization with the various data sets on the first day of the workshop, it became 
obvious that additional data selection criteria were necessary to define a worldng data 
subset. Magnetic field line conjunctions of the DE-1 and DE-2 spacecraft were chosen 
to further narrow the data set. These criteria along with the data variability criteria 
produced the data subsets listed in Table 1. 


TABLE 1. DATA SUBSETS 


DE-1, -2 Conjunction 

Magnetic Local Time (MLT) 

(1) 1981 Day 298 0555 to 0615 UT 

10 hours 

(2) 1981 Day 298 1215 to 1235 UT 

9 hours * 

(3) 1981 Day 299 0600 to 0700 UT 

20 hours 

(4) 1981 Day 302 0700 to 0720 UT 

9 hours 

(5) 1981 Day 302 2300 to 2355 UT 

7 hours 


The starred entry in Table 1 is also a Chatanika conjunction time. It is 
important to note that although, from the events studied, there was only one DE-1, 
-2 and Chatanika conjunction, the Chatanika radar measurements were still used in 
all the other events. In fact, for purposes of examining convection cell patterns over 
the northern pole, it was desirable not tc have conjunctions (measurements at the 
same magnetic local time) between DE-2 and Chatanika but that they be simultaneous 
in time and separated by at least 3 hr in MLT position. 
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Concentrated data analysis of these subsets continued throughout the remaining 
day of the workshop. First, increased resolution (1 hr) RIMS spin, energy-time 
spectograms of all measured ion species (H+, He+, 0+, He++, and 0++,) were 
produced for the times listed in the "RIMS data time" column of Table 1. These 
spratr:,* trams were produced .hiteractively on the MEEDS central computer, and the 
plot flit's were transferred to the SSD remote node where MATRIX camera hard copies 
were produced for all remote node representatives. In addition, Joe Doupnik of UTAH 
processed additional ion density meridian scans from the Chatanika data during the 
chosen data concentration periods at the UTAH remote site, transmitted them to the 
NEEDS node, and created plot files which were hard-copied on the SSL MATRIX 
camera. Rod Heelis produced ion velocity vector plots of his data during the selected 
times and copied additional DE-2 measurements from the DE-2 summary plots, This 
interactive processing produced additional DE-1 RIMS spectrograms, Chatanika color 
meridian scans, and DE-2 RPA/IDM vector plots which were examined by the work- 
shop participants. From this examination, three very interesting science topics were 
chosen which are listed in Table 2. 


TABLE 2. SCIENCE TOPICS 


Science Topic 

Conjuction 

(1) DE-1, -2 cusp study 

1 

(2) DE-1, -2 Chatanika ionosphere 


plasmasphere boundary study 

3 

(3) DE-1, -2 0+ flow study 

5 


VI. WORKSHOP SCIENCE TOPICS 


In this section each of the selected workshop science topics listed in Table 2 
win be briefly discussed and areas of continuing research will be identified. 


A. DE-1, -2 Cusp Conjunction Study: 1981 Day 298 0600 to 0700 UT. 

The DE-1 and DE-2 were in magnetic field line conjunction between 60 and 72 
deg IL near 9 to 10 hr magnetic local time on Day 298. This conjvinction occurred in 
the region of the auroral cleft as identified by the DE-2 Low Altitude Pa^-ticle 
Instrument or LAPI (this data is from the DE microfiche generated by GSFC and sent 
to all the principal investigators in the DE project) and DE-1 RIMS (generated in the 
NEEDS computer). DE-2 LAPI saw a characteristic flux of 1 keV transversely accel- 
erated 0+ ions at 5:57 UT and 71.5 deg IL at the same time that the DE-2 RPA/IDM 
saw a large upward flux of 0+ ions as shown in Figure 1. High altitude DE-1 RIMS 
measurements indicated a narrow band of down going He++ ions with a conical distri- 
bution at 06:31 UT and 71 deg IL, followed by a downgoing conical) distribution of 
H+ ions with accompanying upgoing H+ field-aligned ions between 71.. 3 and 72.9 deg 
IL. The He++ and H+ RIMS measurements can be seen in the spectrogram of Figures 
2 and 3, respectively, where the upper panel for each ion species is an energy-time 
spectrogram of ion flux and the lower panel a spin phase angle-time spectrogram. 

The spacecraft is traveling perpendicular to the magnetic field direction at this time 
so that -90 deg spin phase angle is downwards along the field line in the northern 
hemisphere in this ^spectrogram (this is marked by the dashed horizontal line in the 
bottom panel of each RIMS spectrogram). The spatial and/or temporal separation of 
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Figure 2. This He-*-+ data is from the RIMS experiment onboard DE-1 and displayed in an energy-time 
spectrogram (top panel) and a spin-time spectrogram (bottoiu panel). Note that these high-energy 
(greater than 50 eV) ions are seen predominately flowing down the field line marked by the 
dashed horizontal line in the bottom panel. The DE-2 RPA/IDM data of Figure 1 is 

coincident with this RIMS pass. 
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the He++ and H+ ion flows is interesting* and may be a result of EXB drift coupled 
with ener^ dispersion of the observed ions. 

Several important questions remain to be answered by more comprehensive 
analysis : 

1) Does the upward flux of 0+ ions seen by DE-2 RPA/IDM equal the low- 
energy H+ ion flux seen at higher altitudes near the poleward edge of the cleft by 
DE-1 RIMS? 

2) Does the "gap" in the 1 keV ion fluxes of the DE-2 LAPI instrument at 
05;57:15 map to the H+ field-aligned flow region of DE-1 RIMS? 

3) Where is the cusp boundary at high altitudes as defined by the DE-1 High 
Altitude Particle Instrument (HAPI)? 

4) What is the source of the downgoing low-energy H+ and He++ conics seen by 
DE-1 RIMS and what causes their spatial and/or temporal displacement? 

Further investigations using the SCAN network will hopefully provide some answers 
to these questions. 


B. DE-1, Chatanika Plasmapause Conjunction Study: 1981 Day 299 0600 to 0700 UT. 

The DE-1 spacecraft was in magnetic field line conjunction with the Chatanika 
incoherent radar facility between 06:30 and 07:12 on Day 299. This conjunction 
occurred less than 10 min after the Chatanika facility obtained the ion density 
measurements shown in Figure 4. In the Chatanika meridian scan plot, the F region 
can be seen between 250 and 450 km altitude and in latitude from Chatanika to 1200 
km south of Chatanika. Note that near the center of this plot there is a sharp 
density depletion which occurrs at the high-latitude convective boundary which 
separates the lower latitude F region from the polar cap ionosphere (400 to 1200 km 
north) . The polar cap ionosphere has higher densities and extends to higher altitudes 
as the result of auroral precipitation, evidenced by vertical stripping of the polar 
cap ionosphere spectrogram. Such observations as characterized by the low-altitude 
ionosphere observers would like the convective depletion boundary (density depletion 
at 400 km north) with the plasmapause boundary at high altitudes. Such is not the 
case as shown by looking at the DE-1 RIMS H+ spin, energy- time spectrogram in 
Figure 5. 

The RIMS data is plotted as a linear function of invariant latitude which is 
directly comparable to the features in the Chatanika plot in Figure 4. From the RIMS 
data, the plasmapause boundary is located at 7:06 UT or at 59.4 deg IL. Outside the 
plasmasphere is a region of warm plasma characterized by conical and isotropic 
distributions from 06:49 to 07:06 UT which maps directly to the quiet F region plasma 
between 69:3 and 59:4 deg IL. Poleward of this, DE-1 RIMS observes intermittent 
field-aligned flows of H+ which maps to the Chatanika polar cap ionosphere. 

This new low- and high-altitude comparison of corresponding ionosphere and 
magnetosphere boundary features is very exciting and raises many new questions: 

1) Where does the DE-1 HAPI locate the plasmasheet boundary (this data would 
come from the Southwest Research Institute who is scheduled to be on the network 
in 1983)? 


12 


Cl f ICK V* 


t ]0 I i - 


— n . " n .3 -i 


• • — .. ii". 4 • * "" 

in U ) -^j u I 


□ .. g- 2” '*,-"* i 

*-"£) „ ^ 


■ 3 " '«^'-* •■ A." 


- “%• 

. M 




Si 


:■- -'*« ■■ 
, W.tli' "jfS 

*JF* 4 H V< 

■•' ■■ *^ - . -r 

„”* . : . Ill' < 1 , - '..., 

I 'll' ''h,,, ,1 

'.. m • "' ! |l V, HI 

. , '"m.II! •'!^''ii 

”■ H '’i;i u*j ' . 

m «n ' 


t- 


4 

(1) 

CJ 

«-> 

_ 

>. 

1 ) 


t 

0) 

c 

o 

u 
1 ) 

■3 

-» 

(/} 

•t 

h- 

P 

5 

1.0 

c 

K-l 

« 

Cl 

o 

in 


c 

CB 

U 

»- ® 

C 8 o 5 i 
• 0^:5 a 

U’O ^ P c /2 

^ o O 0 ) OS .2 

2 > 4-0 a> ♦-' 

E ts 3 "C w 3 

2 -E -i- ts bo x; ^ 

5 1 S o -o ’C 

5 ' 2 ^ “o £| 

•C C 3 "* »i 5 i) 

H O O ® TV. 

. S e g 

P 

E -C TJ o </2 « 

^ 4 ) ® J 3 

3 C ,3 o -r 

CO t/l O ^ ^ « - 1 ^ 


o-t: 5 S 

« E c o fci "0 

2 c 2 E ^ 

•— ' " .Q 'S’ > ♦-• 

<« c ^ C ‘5 


^ 8? 

E efl _ B 0) 2 

.2 — E m , 0 ) 

"P 2 o ^ ^ 




8 S 8 S 8 ?. 8 R?.'^S?/J 

»t rn I'l I'J I iJ 


^ a> ♦-< 

. u JS 
c8 3 bo 

.-S S| 

p E 


13 


PACw T3 
OF POOrt QUALITY 




■t ^ 

• • 


K • ^ p H 
fvj fO ^ 

»D Q ’H 
_ • • • 

. ff) Q 
(M N 


N 

't 


m 'I- in cn 00 

U") N • • • 

ID . iD (T> cn 

fVJ 'T 


UJ • N (T 
(VJ 


qp 3 »D 00 in 
in 00 • • ■ 

^ N m 

(n (j^ in 
In 

3 n ^ 0) (\J 

(S • • • 

• cj' op 

»-• m 


fVJ 


m 


o5 • m 


TJ> ^ 


m u» ^ 

n «H »H »D 




^ ^ W ww 

E 

- i''z 

t*- g £ 

CA On 

.5 ♦- ^ 

^ 2 ° 

5£ 

o «5 c •© S!, 

-c S p « 

w £ 0> *2 ” 

Q cO 3 

c6 a V V) 
a X « a> 
c «-• w "O 
E 3 

W -M 

^ a I 5 ■§ 

= s! M ^ . 
« S Cc E ^ 

a'O '* 73 
'” o fci 
r m O 
bceo C 


00 

T? 



0) 


O 3 W £1 -JH M 

$ .ts fa 2 ^ 

^ a & 0^ Q> Qj 

w 5 .S' ♦- -O »; 


^ ^ 
o ^ 

^ ^ Z d jT 

I c w &'5 

W CO 3 . .5f 9" 

Q r 2 x: o 
S « c 
W > O 5 o 
S C J; o V •'" 
« •’- a c > 

« 0 ) a, « -D! 
hot x: a -5 
c c 

•O a C ^ 

c x: 

o ♦- a o 

a ^ 00 > u 

Si'S'! 
s » ‘■’S-a 

o _ CO O OJ 
o -o ^ CO 
4) "i-* 

Qj 4-1 c n« n 
O « m ° 

tj O 4 -> 0 ) 

^ a«-fi 

. CO U c 
ITS 00 

^ ^ 
g 5 x: 

^ 00 •'- 
^X1 




14 



Oa'GIWAL PAGg ,g 
OP POOR QUflUTV 

2) What is the rolation botvvoon tho warm-li’apped plasma ti’oug'h population and 
the qulot nlgditsido ionosphei'o? 

3) Do tho ion beam bursts scon by DIS-“1 RIMS map to tho onhnncod density 
regions in tho polar cap topside ionosphere? 

Those questions arc now being investigated. 


G, DE=1, »2 Of Outflow Study; 1981 Day 302 at 23;50 UT\ 

DH«1 and DE=*2 wore in magnotie field lino conjunetion near 23; 20 ovox^ the 
northern polar cap. Soon after conjunction at 23;il3 GT, DR»1 RIMS saw an intense 
burst of fiehh-aUgnod Of outflow as shown in tho DR'=l RIMS spin, enorgy=timo 
spectrogram of Riguro 6. Tho mean energy of the Of ions is only 1»5 oY. These low*- 
energy ion outflow events have been seen about 5 percent of the time in the DR-1 
RIMS polar cap data, and indications are that they may bo associated with auroral 
activity . 

The DR- 2 RPA/IDM Inis also observed occasional largo vortical fluxes of Of 
ions out of the ionosphere (not shown) . It is hoped that by using this conjunction 
data, it will bo possible to correlate the DR-1 and DR- 2 Of outflow observations, 

As one can see from this brief soioneo summary, tho stage 1 workshop bogaix a 
phase of correlative space science which is extremely interesting and exciting. It is 
also quite clear from this discussion that the work has only begun, and much eo- 
ordiuatod scientific analysis remains to bo done. It is anticipated that the network 
will bo a valuable tool in achieving these objectives, 


VII. WORKSHOP RVAUIATION AND RRGOMMRNDATIONS 


The evaluation of the SCAN netwox’k system auust be based px’imax'ily on tho 
suceoss in obtaining tho desired sciontifie objeetivos and goals as outlined in the 
section on workshop philosophy. Regarding the seicnoo objectives, the wox*kshop was 
an outstanding suceoss, but much of tho success of tho workshop is duo to the 
recognition and appropx'iate preparation within tho constraints of tho system, Tho 
following summariisea tho snccossful points of the workshop; 

1) Participants obtained an appreciation of all the available data bases. 

2) Continued x‘esearch is being eaxuded on, with future seienoe publications 
being planned, 

3) Tho centralis’.od RIMS data base was by far tho easiest to use and most 
accessible, 

4) The SCAN network provided a system of shared rosourees which includes 
hardware and software. 


It is important to point out that a number of problems have been encountorod 
and idontified with a xvorkshop of this typo that must be examined earefully in order 
to improve future workshops. The followtag summariKos several of the problems; 
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Figure 6. Another RIMS spectrogram but for low-energy 6+ ions. Note the upgoing (H ions (along the 
solid horizontal line in the bottom panel). These flows are seen only during times when 

no H+ and He+ flows are measured. 



1) Before the workshop* the node I’epresentatives worked mainly on their own 
data set and were not prepared to examine other data bases at the start of the 
workshop . 

2) Some of the software and hardware devices were little utilized, limiting the 
output of the workshop. 

3) ORACLE, the data-based management language on the NEEDS node, was 
not significantly used. 

4) There was a need for additional data bases to resolve questions. 

5) Some software analysis programs were not "user friendly." 

6) There is a need for better systems-level software to enable the PDF 
machines to be readily accessible by network users. 

7) Device- dependent plot files generated by different graphics software were 
generally difficult to display. 

The following is a list of recommendations which will help solve many of the above 
stated problems: 

1) More diverse data bases are needed in the archive. 

2) The size of the archive must be increased considerably. 

3) A standard, device-independent plot file structure needs to be adopted by 
the everyone on the network. 

The SCAN network provides scientists with several capabilities that were not 
available in the past. Although the NEEDS central archiving and data ingest system 
is helping to develop the mass memory technology, the SCAN network uses currently 
available commercial networking technology. Space plasma physics scientists through- 
out the country are using computing systems which range in age (capabilities 
decreases dramatically with age) from several to nearly 20 years old. Even today, 
just the trading of data is a monumentous task which is accomplished through the use 
of computer cards or magnetic tape media and is always labor intensive. Invariably, 
software necessary to read the cards or tape into a familar format must be written. 
This procedure has produced, in general, a high impedance to doing correlative 
work. In a network environment once the data is communicated over the "line", 
one can put it into a familar medium. Data communication over the SCAN network is 
done with relative ease and is not labor intensive. 

The trading of software has not been extensive in the space science community, 
in the past, particularly because of the diversity of computer systems used and once 
again its labor intensive nature. In a network environment, such as SCAN, software 
trading is extremely easy and, as this document demonstrates, has proved to be 
extremely beneficial. Along the same lines as the trading of software, the network 
supports the transmission and reception of manuscripts. This significantly decreases 
the time it takes to perform correlative work when authors are located across the 
country . 
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Another feature of the network which has been extremely useful is the mail 
facility. The mail facility allows for rapid exchange of information between scientists 
on the networl^. A user is notified of the mail when he logs onto the system. The 
mail is accumulated in a file in each user’s account and can be printed or deleted at 
any time, thus providing an easy means of documenting any message. The ability to 
accumulate mail allows one to find time to handle many messages at a more convenient 
time and not be bothered by a stream of phone calls. 

Based on the sharing of software, the coordinated effort of data analysis, 
program development, and the workshop period, the DBMS system and network con- 
figuration is, in our opinion, an extremely beneficial step toward determining an 
effective and desirable method of future data analysis. 


VIII. IN-PERSON VERSUS REMOTE WORKSHOPS; A COMPARISON 


One of the main objectives of the SCAN network project is to accommodate co- 
ordinated data analysis without leaving one's institution. This objective is already 
met by the network, but there are several constraints. These constraints are 
thoroughly discussed in this section, and a procedure has been defined that will 
eliminate them within the next few years. Although the computers in the network can 
easily handle the exchange of data (with some constraints, see below), the direct 
scientist-to-remote scientist interface is a more difficult problem. During the first 
SCAN workshop, time was set aside for a discussion of the advantages and dis- 
advantages in doing a totally "remote" workshop or doing an "in-person" workshop. 
Although the first workshop was initiated as an "in-person" workshop, there were 
five telecons previous to the workshop for which the remote participants sat behind 
terminals on the network. Unfortunately, during the telecons, science was not done, 
since testing the system and finding problem areas were the primary purposes of the 
telecons. The following thoughts were expressed at the first workshop on this 
subject. 

Advantages of an "in-person" workshop are: 

1) A face-to-face meeting was believed to be better, to avoid getting lost in 
trying to understand the fine points about a particular data set when emphasis 
should be placed on trying to understand the physics behind the observations. In 
addition, correlative work would become secondary to looking at particular aspects 
of your own data on a new system. 

2) The scientist is able to get away from distractions with the presence of 
visiting scientists providing substantial obligations on the hosts. 

3) The participants quickly decided how and what to do (previous telecons did 
not solidify this problem). 

4) The participants generally felt that we wouldn't have been as productive. 
Scientists could point to features in the data plots asking for interpretations or 
explaining the data. 

5) Earlier phone conferencing was poor in terms of hearing all parties. This 
was generally a bad experience on every occasion and left the impression that a 
telephone voice link during a .remote workshop would be disasterous. Computer text 
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communication (mail) is available, but it i^ too slow to be productive scientifically, on 
the time scale of a workshop (seconds) . 

6) Face-to-face discussions certainly provide a quick means of generating ex- 
citement among scientists that would be difficult to do remotely. 

7) The "in-person" workshop cuts down on the amount of software effort 
needed for full graphics support of remote nodes (note this is a current and not a 
long-term problem). 

8) "In-person" workshops allow for easy monitoring of the scientific progress 
and network usage. 

Disadvantages are: 

1) If plotting or programming problems arise there is not time to pursue the 
problem. Remote woi’kshops would suffer from this also except that to some extent 
they could be rescheduled for the next day or a future date. 

2) In general, the cost both in terms of time and, money is considerably 
gTeater for the same workshop time (assuming a network already exists) for a 
central workshop, compared to that for a remote workshop (cost and time of travel, 
subsistence, etc.). 

Certain elements were identified that are essential in order for a "remote work- 
shop" to have any degree of success. Two major elements are: remote scientists must 
be able to look at data plots, and reliable communication with all participants is 
essential. As the use of the network continues and remote workshops are carried out, 
more elements will be identified. The following takes a closer look at these two points 
in relation to existing software and hardwai’e constraints. 


Problem : 

Remote scientists must be able to look at data plots. 


Possible Solutions ; 

1) Obtain all the data and the software used for that data set from the node 
responsible and network it to your site or mail tapes of this information. The mailing 
of tapes of this type only makes sense (if you have determined that everything is 
needed inhouse) when nearly identical systems are involved. There is no such thing 
as institutions with identical systems in the space sciences. Networking the data and 
software using current network and communications technology can only be done 
successfully with very small amounts of data and software (it would take 1 hr to 
transmit 1 hr of RIMS data over the network to any node). However, stored packets 
of data (raw or processed) will be useful to examine locally for science details. 
Currently, very little data is packetized, since this is a new concept of the DSTP 
program which is not used significantly outside the network. As high data rates of 
communication are used, the method of. transferring data and software quickly 
becomes much less of a problem. However, there are still the problems of software 
running on one system that will not necessarily run on another system and that 
programs may be using a plotting device that is not available at your institution 
(see next section). 
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Additional points v/hich must be considered in this scenario are; documentation 
must also bo distributed to all nodes, including instructions as to how to build and 
maintain the software librai*ies; there is then an obligation on the people who 
originally wrote this software /documentation to provide updates and now programs to 
the remote nodes as they become available. This is not a negligible workload. 

2) Generate the plots remotely and network them to your node. This produces 
a graphics display problem explained in the next section. 


Problem : 


Few institutions have the same graphics devices for displaying the generated 
graphics plots. 


Possible Solutions; 

1) Buy everyone on the network the same graphic devices. The same plotting 
device does not ensure that plots generated at one node can be read by another 
node with the same device. Example, UTD plots (generated by IGL) could not be 
replayed successively by the SSL node even though we had the same devices. All 
SSL plots could be replayed at UTD but they were generated by the MSSL plotting 
package. We believe a diversity of plotting devices has distinct advantages; the 
same plot devices on a network is only a short-term solution. Inhomogeneous devices 
foi’ce one to use device-independent plot files and meta- file-based graphics. 

2) Buy everyone not only the same graphics device but the same plot 
language. This produces another problem; not everyone has the same machine (DEC, 
UNIVAC, IBM, etc.) or more importantly the same size machine; and, therefore, the 
graphics language chosen must fit on all machines. This means that the graphics 
language must fit on the smallest machine used. For example, although the SSL 11/34 
has IGL (a modest size graphics library) on the system, the programs which use this 
library have a very small amount of space in the machine to manipulate data. The 
capabilities of a graphics language generally increases in proportion to the size of the 
machine it is designed to operate on. It is unreasonable to assume that institutions 
whose computers have the capacity for extensive graphics softwai’e will use a small 
and limited language such as the MSSL gx’aphics language. Also, graphics packages 
can come and go. PLOTIO (IGL is based on a PLOTlO-like library) is no longer used 
extensively since the advent of plotting libraries such as DI3000 or DISPLA. In 
addition, PLOTIO and IGL are not supported by Tektronix but merely provided by 
the company. 

3) Use a standard device-independent file structure. This will get around the 
device and graphics language problems, however, it produces additional problems. 
First, IEEE is just beginning to define a "standard” device-independent file 
structure. This standard is called the "core system." IEEE's work in this area will 
probably be complete in a few years. In addition to the core system, there are 
device-independent file structures (or meta files) already in use by plot libraries 
such as DI3000 and DISPLA and one used at LANL. These meta file formats are 
different and are not completely compatible with the core system as presently 
defined. Most plotting libraries do not have any facilities for generating meta files. 

It is unlikely that a core system for the MSSL library will be available in the near 
future unless it is written in-house. 
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Problem : 


Good sciontist-sciontist communication. 


Possible Solutions; 

1) It is essential that the communication between scientists not be significantly 
degraded for a remote workshop, over what is available for a central workshop, 
otherwise the scientific interchange and ultimate scientific output will be seriously 
impaired, When one considers the subtlety with which people communicate, this is 
clearly not a trivial problem. A solution requires good (i.e., at least acceptable) 
voice communications between participants. Since this does not appear possible with 
existing telecoa equipment, then we must go to headsets. Apart from the obvious 
disadvantage of such equipment (freedom of movement, etc.), this is likely to be 
more acceptable than poor telecon quality. 

2) A superior solution would be video links between participating nodes, 
though it is arguable what good this would be unless several members at each node 
could be viewed simultaneously by the other node members. Also, costs would need 
to be considered, the cost savings brought about by having remote workshops being 
eroded by expensive video links. However, savings in scientists time would still 

be significant. 

The imple.mentation of remote workshops is t'^n ongoing project of the SCAN net- 
work. Two major areas of work necessary to overcome the problems discussed in 
this suction that we are putting considerable effort into are; adapting a meta file 
structure as a standard for the network and the development of a scientific graphics 
and communication work station that accommodates the networking. 


IX. GROWTH AND FUTURE OF THE NETWORK 


The SCAN network provides very easy access to large, multifarious data sets 
with powerful, easy-to-run software for large periods of uninterrupted time. We are 
confident that this network will continue to provide a means for accomplishing 
scientific research in the easiest and most cost effective manner provided that we do 
not lose track of the exploding technology around us and utilize this technology in 
such a way that will keep the system upward compatible. 

Several new nodes have just been added to the network, such as the Code 960 
VAX '’omputer at GSFC and computers (a large local area network) at the Los Alamos 
National Laboratory. The addition of LANL will enable other network nodes to have 
access to a large and fast "number-crunching" computer for modeling purposes (a 
Cray machine) , making it possible to compare sophisticated theory with actual 
observations. Within the next few months, two new nodes will be added to the 
network: Southwest Research Institute (SWRI) and the University of Michigan, with 
many more research centers being considered for the future. With the addition of 
new nodes comes more and diverse data bases, more distributive computing power, 
and more scientific expertise. This situation naturally provides the opportunity to 
hold many diverse future workshops. This kind of growth is necessary to fully 
develop the capabilities of the SCAN network system. 
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The network hardware structure is also expected to grow considerably over the 
next few years. The nodes that will be added to the present star configuration will 
form small networks of their own. For example, SWRI will be connected to UTD, This 
enables continued correlative work with the small networks during the times when 
the central DBMS facilities are temporarily down and reduces substantially the com- 
munications cost without reducing functionality. It is also expected that progress will 
be made in using satellite communications instead of land lines. The development of 
an economical "micro-based” graphics work station based on the network is currently 
on the drawing board and will be implemented. The network work stations are being 
designed around the scientists' needs for computer-aided analysis tools. These are 
just a few directions that are being pursued within the scope of the SCAN network. 

The Space plasma Computer Analysis Network (SCAN) is in its infancy but is 
having a major effect on NASA’s data systems of the future. The network, with 
advice from the Data System Users Group (DSUWG), brings into NASA and the user 
community needed technological expertise, increasing the capabilities and productivity 
of today's scientists. 
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APPENDIX 


This appendix, in the following form, was available on the network before and 
for a short time after the workshop. It is important to note that several changes in 
the network that have occurred since the workshop are not reflected in this appendix. 
For instance, at the time of the workshop the network was called the MSEC /NEEDS 
network which has now been changed to SCAN. In addition, Section 8 is completely 
obsolete, since right after the workshop individual packets were accessed auto- 
matically from the desired input time period. 


WORKSHOP OPERATIONS MANUAL 


1 . 0 Introduction 

This document is intended to act as a reference for the MSEC /NEEDS workshop, 
to be held on August 19-20, 1982. It includes documentation on how to run the 
available RIMS, Chatanika, UTD and network programs, whe?’e the data are located, 
suggestions for the sharing of the facilities, making hardcopies of plots, etc. 

If you are not familiar with the NEEDS node (DBMS central VAX system) , 
analysis, and networking software, and there are therefore omissions in this 
document from your perspective, please let us know so this document may be updated 
accordingly. 

2.0 Intended mode of operation 

The ES53 Data Analysis Lab will be the "center of operations" (unless the SSL 
11/34 goes out with hardware problems, in which case there will be a mass move to 
the NEEDS VAX). However, it is expected that most plot generation will be per- 
formed on the VAX; then actual plotting will be done on one of the three available 
plot devices in the data room. 


'"OTE : 

USE OF THE SSL 11/34 FOR PROGRAM 
DEVELOPMENT THROUGH THE DURATION 
OF THE WORKSHOP IS PROHIBITED! 

In addition, the submitting of batch jobs on the NEEDS VAX is discouraged - 
not only has no "software" or documentation been generated to support this mode 
of operation, it is suspected that many more requests for plot generation would be 
submitted than the VAX could cope with. Thus, the workshop would very rapidly 
cease to be "interactive." By limiting programs to the two or three that will be run 
interactively with the available terminals, total interactive throughput will be main- 
tained. Please follow these guidelines. 

3.0 Plotting devices 

The devices which are available at SSL, and for which we have programs to 
drive, are: 
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Plot device 


Hardcopy Unit 


Tektronix 4027 color monitor Matrix camera 

Tektronix 4014 graphics terminal Tektronix H/C unit 

Princeton 8500 graphics terminal Tektronix H/C unit 

Whenever possible, please use the monochrome plot program EXCEPT where you 
really do need color* The matidx camera will support Polaroid 10x8 hardcopy film 
(very limited quantities), and also a 35 mm camera (for which film is more readily 
available, though cannot bo developed in the timeframe of the workshop). 

See the section "Hardcopying'* for multiple-frame files. 


4.0 Accounts 

On the SSL 11/34 please use the following accounts for scratch files, plot files, 

etc. ! 

[UIC] Account Name 

[303.001] NET 

[311.001] NETSSL 

[307.001] NETUTAH 

[306.001] NETUTD 

[305.001] NETNBEDS 

Of course, if you are a permanent resident of SSL, use your own account if you 
so wish. The above accounts are also available on the NEEDS VAX, so use those when 
you log in. When logging on the NEEDS VAX from the SSL 11/34 (this is remote log- 
in) please use the same account. 

Type HELP UICLIST on the SSL 11/34 to see a list of the account names /UIC's. 


NOTE: 

KEEP OUT OF THE SSL[200,*] DE ACCOUNTS, 
AND THE NEEDS: :[NETLIB] ACCOUNT 
THROUGH THE WORKSHOP! 


5.0 Remote log-on's 

Joe Doupnik has spent a large amount of time removing the bugs from the 
program RVT (remote virtural terminal). A complete description of this program is in 
the DECNET-RSX manual. To x’un this program all one does is to type RVT and 
answer the questions (see DEDASH, volume II) [8]. 

Logging onto the NEEDS VAX in one of the network accounts will allow you to 
use the DEP facility for running DE RIMS programs (see later). Normally you will 
generate a plot file (you will not drive a plot device directly) , and you can then 
send the plot file to the SSL 11/34 with an NFT command: 

NFT SSL"NET NET"::=plot name. pit 

Altei*natively , if you log into one of the terminals used as a plot device, you 
may use NFT to plot the file directly, viz: NFT 
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TI:=NEEDS/NET/NET: ;plot file. pit 


This has the advantage, of course, that you do not generate a load of old plot 
iiios on the SSL 11/34. See the DECNET documentation for more details. 

6.0 Programs available 

This section discusses the data analysis programs available on the central 
NEEDS VAX. 

6.1 RIMS data 

There are three data bases that will be used in this workshop; RIMS data from 
DE-1 (residing on the NEEDS VAX), IDM and RPA data (residing on the NEEDS 
VAX and at UTD) , and Chatanika data (residing on the NEEDS VAX). Each of these 
data bases has their own software. 

The principal RIMS programs [8] available are: 

1) LSTDTl ■* List data times for a data set 

2) LSTMFl - List MFl data to a file 

3) SENTGS - Spin /energy versus time spectrogram 

4) RPASGS -- RPA versus spin plot (greyscale /color) 

5. CESPEC - Count versus energy spectrum (line plot) 

6. CSSPEC - Count versus spin spectrum (line plot) 

7. CTSTIM - Count versus time (line plot) 

8. PORBC - Plots DE-1 orbit segments (color only) 

There are two versions except for PORBC of the graphics programs, one to 
drive the 4027, the other to drive the Princeton /TX 4014. The task names (.EXE files) 
for the above programs are, therefore, followed by M for monchrome (4014), or C 
for color (4027). The listing programs (LSTDTl, LSTMFl) have .EXE names the 
same as the program names. Use the .EXE name when you want to run a program. 
Since you generate plot files, we have adopted a default file type for the plot files. 

.PLT for the monochrome plot files (Princeton /4014) 

.COL for the color plot files (4027) 

Please stick to this convention; it may help to minimize chaos. 

Example output, detailed documentation, and a detailed description of the input 
required for the monochrome versions of the programs are found in the DEDASH [8]. 

6.2 Chatanika plots 

There is currently one program in the NEEDS VAX that produces Chatanika 
radar plots; it is called SCANPLC. This program asks for a color bar file (used as 
a lookup table), an ELS file of input data, and the start time you need. 
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6.3 UTD plots- 


Thoi’G ai’G several programs that will plot UTD data that is at UTD. They are: 
NETREP, TEXMETC, and TEXMETM. All these programs are in the NET NET account, 


NETREP is a network replay program that will display plot files (you must know 
ahead of time if it is a 4027 or a Princeton 8500 plot file). 


TEXMETC is a network plotting program that reads a UTD device-independent 
META file and plots it onto a 4027. 


TEXMETM is a network plotting program that reads a UTD device-independent 
META plot file and plots it onto the Princeton. 


7.0 DEP procedure 

DEP stands for DE processing (of RIMS data only) and is a command procedure 
used in all network accounts on the NEEDS VAX. The DEP facility is intended to 
simplify running of the RIMS programs listed in Section 6.1. To do this simply type: 
DEP<ret> 


DEP is menu driven so little explanation is necessary. The procedure asks what 
the data source is and then asks which program you want to run. All the RIMS 
wox’kshop data has been packetized, so respond with a P for Packet data. You may 
answer H for help to either of these questions to get more information. The assign- 
ments to put the plot output into file are performed automatically. If you reply with 
<roturn> in re.sponse to the "plot file name" question, the output plot file will be 
"program. PLT" or "program. COL," depending on whether you are running mono- 
chrome or color programs. The output for the LSTMFl program goes to a file called 
FOR002.DAT (sorry about that). If you simply type 

DEP program-name <ret> 

DEP assumes you want to run prograai "program-name," and that you will be 
working from the PACKET data; it does not prompt for which data type. 

For programs (SENTQS , RPATGS) that require a file name with contour values, 
hitting return will give you file [NETLIB.DElCONTRS.TXT. This contains the 
approximately logax’ithraic count sequence to be seen on all the summary DE RIMS 
plots. A second file is [NETLIB.DE3CONTLIN.TXT which contains a linear sequence 
of count values. Alternatively you may create your own with the editor (values are 
read in under * format, and there must be no more than 14). 

8.0 File name input for packet data 

All the DE RIMS programs ask for "data file name" at the beginning of the 
run (it does not loop back to request as alternative input file) . If you are running 
from packet data, this data file is a file of the type in DRl; [DEARCH] ; i.e., 
packetized data. Each packet contains approximately 3 min of data; if you are doing 
intensive analysis on only 3 min, you can supply the packet name directly (do 

DIR drl: [DEARCH] *.ORC 
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to see a list of packets). Normally, however, you will be processing on a larger 
quantity of data than this, and the way this is done at present is to put the list of 
packet file names in a .CMD file. Then respond to the "input file name" prompt with 

©file name 


where file name contains the list of packets. If the file type is .COM you do not 
need to specify it. Ensure that you have [DEARCH] preceeding each of the file 
names in the list. 

The files D297.COM, D298.COM, D299.COM, and D302.COM contain lists of 
» packets for each of the four workshop days, but if you are working at the end of 

the day things will be very slow, because at the moment the programs sldp through 
each file (rather than skipping files). Therefore, please copy what archive files 
» you need from the above com files. When the central data base management becomes 

fully operational, this procedure will not be necessary. 

i 

9.0 Hardcopying at the SSL node 

Use of the Matrix will not be discussed here; there are plenty of people who 
know how to use it. 


It is possible (and frequently desirable) to generate multiple-frame plot files. 
Simply using PIP or NET to replay these files will cause a problem if you want to 
hardcopy all or some of the frames. Two programs exist (on SSL 11/34 type DEP 
prog-name) to replay these files, frame by frame. You will need to reassign TX: 
to the actual device you are using if you are not using the default TX : . 

Program Output to; 

RP4027 TK: 

RP4010 TX: 

Example: >DEP ONLINE 

>ASN TT6:=TK: 

>RUN RP4027 


You will need to type DEP ONLINE, before you run either of these, since they 
use DEP offline /online convention. The RP4010 program has the capability to auto- 
matically hardcopy all frames. This will only work when it is driving a device to 
which the hardcopy unit is attached by a multiple pin connector (e.g., the 4014), 
but not when it is only connected by a BNC (e.g., the Princeton). 

The programs should be self-explanatory when you run them, reply with the 
plot file name. These programs currently work only when the plot files are on the 
SSL 11/34. 

(Julian Johnson and James L. Green, August 17, 1982) 


27 


-M 


% 


REFERENCES 


1. NEEDS Systems Team: NEEDS; System Concept, GSFC, February 28, 1979. 

2. Thomas, Douglas: NEEDS; Data Base Management System Concept, MSEC, May 
30, 1980. 

3. Gary, J. P., Posey, K. W., Durachka, R. W., and Abilock, J. G.: NEEDS Data 
Base Management System; Functional Requirements, GSFC, March 20, 1980. 

4. Chappell, C. R., Fields, S. A., Baugher, C. R., Hoffman, J, H., Hanson, 

W. B., Wright, W. W., Hammack, H. D., Carignan, G.' R., and Nagy, A. F.: 
The Retarding Ion Mass Spectrometer on Dynamics Explorer-A. Space Science 
Instrumentation, Vol. 5 (4), 1981, p. 477. 

5. Leadabrand, R. L., Baron, M. J., Petriceks, J., and Bates, H. F.: Chatanika, 
Alaska, auroral zone incoherent scatter facility. Radio Science, Vol. 7, 1972, 

p. 747. 

6. Hanson, W. B., Heelis, R. A., Powers, R. A., Lippincott, C. R., Zuccaro, 

D . R . , Holt , B . J . , Harmon , L . H . , and Sanatani , S . : The Retarding Potential 
Analyzer for Dynamics Explorer-B. Space Science Instrumentation, Vol. 5 (4), 
1981, p. 503. 

7. Heelis, R. A., Hanson, W. B., Lippincott, C. R., Zuccaro, D. R., Harmon, 

L. H., Holt, B. J., Doherty, J. E., and Powers, R. A.: The Ion Drift Meter 
for Dynamics Explorer-B . Space Science Instrumentation, Vol. 5 (4), 1981, 

p. 511. 

8. Magnetospheric Physics Branch; DEDASH (Dynamics Explorer Data Analysis 
Handbook), MSFC, February 1983, latest revision. 


28 


ft 


I 


APPROVAL 


MSFC SCAN STAGE 1 WORKSHOP 

By James L. Green, J. H. Waite, J. E. E, Johnson, 
Joseph R, Doupnik, and Rod A. Heelis 


The information in this report has been reviewed for technical content. Review 
of any information concerning Department of Defense or nuclear energy activities or 
programs has been made by the MSFC Security Classification Officer. This report, 
in its entirety, has been determined lo be unclassified. 



•it U.S. GOVERNMENT PRINTING OFFICE 1983-646-058/231 


29 


